Before moving on, let's say a few things about variable names. If you want to name some object in Python you have to abide by a few 'concrete' rules:
Below are a few examples of the above three rules in action.
In [1]:
print = 10.20 # Rule 1: "print" is a reserved word in Python and therefore we cannot use it.
0sales = 10.20 # Rule 2: cannot start a name with a number.
this has spaces = 10.20 # Rule 2: space character is punctation.
thisnamehasa+init = 10.20 # Rule 3: Fails because "+" is a special character in python (addition)
In addition to the above ‘concrete’ there are also a few guidelines that describe "best practices":
For the last three bullet points I said "unless you know what you are doing", let me explain that quickly.
By convention, variable names in ALLCAPS are supposed to have a special meaning, and that is these are values that should NOT be changed by the program at runtime.
Mathematical constants are a pretty good example; for most applications you probably don't want to change these values while the program is running. For example, under what circumstances would you want to change the value of PI while the code is running?
In python we denote constants by naming them in ALLCAPS, and I would recommend you follow this already agreed upon practice; after all, if everyone uses the same naming conventions then all code is that little bit easier to read.
In [ ]:
golden_ratio = 1.61803398874989484820 # okay name
GOLDEN_RATIO = 1.61803398874989484820 # better name
As for using underscores and captial letters in names, well, thats to do with classes, which I do not cover in this lecture series. All you need to know right now is that underscores and capital letters are best avoided.
Anyway, here are a few more examples:
In [2]:
# superbad (nonsense name, mixed case, starts with underscore):
_QWeRTy = 10.20
# bad (still nonsense):
qwerty = 10.20
# poor (descriptive, but mixed case is very annoying):
SaLestAX = 10.20
# better (most boxes ticked!):
salestax = 10.20
# even better:
sales_tax = 10.20
# WAAAYYYY over the top (descriptive doesn't mean "write a novel!")
this_is_the_sales_tax_for_the_beer_I_bought_on_a_summers_day_in_1965_or_was_it_1967_I_cant_remember = 10.20
So in the above examples we saw a few terrible names and two reasonable ones. “sales_tax” is my top-pick because the name tells use something about our data and at just two words long it is concise.
In C# the usual naming convention is to use snake case. So a variable in C# should be called 'salesTax'. In Python we tend to use underscores to split up words. And thats another reason why 'sales_tax' is my top-pick.
The last thing I would like to say about variable names is that very good names can negate the need for comments. Pep8 (the main style guideline for Python) recommends that we use in-line comments sparingly and comments should also avoid stating the obvious; needless comments only serve as a distraction.
Don't get it twisted; we should write comments, but they should be good ones. The real point here is that good code should explain itself.
Here, let me show you can example.
In [19]:
price = 1000 # including sales tax
So this bit of code isn't actually that bad; the variable name "price" is a reasonably good one (short, readable, descriptive) and the comment is helpful. All in all, this code is decent, but that doesn’t mean we cannot do even better:
In [20]:
price_after_tax = 1000
All we did here is change our variable name to be a bit more descriptive. And now since our variable name states that this figure includes tax we don't need the comment!
Show, don't tell.
The point of today was to make you aware that programming is not just about writing code that machines can understand; Good code is understood by both man AND machine.
Below is three lines of python code, the only thing you have seen yet is the '*' symbol which means multiplication. The Syntax:
{number}*{number}
Your task comes in three parts:
In [ ]:
# WTF does this do? Place your bets now...
cake = 3.14
diameter = 2
belt_size = cake * diameter